Mobile communication device based monetary transfer system

ABSTRACT

Systems and methods are disclosed for performing transactions using secure images. A device may collect transaction details and initiates the creation of a secure image. Upon creation of the secure image, the device may provide the secure image to second device participating in the transaction by displaying the secure image in a manner that allows the second device to capture the secure image or by providing the secure image in an electronic message. The second device may use the secure image to identify the transaction by providing the secure image to a secure server. Upon receiving the secure image, the secure server may provide transaction details to the second device. The second device may then send a confirmation of the transaction to the secure server, which may then complete the transaction. Use of the secure image allows the transaction to be performed without exposing sensitive transaction details.

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 61/507,143, entitled “Mobile Communication Device Based MonetaryTransfer System,” filed on Jul. 13, 2011, which is hereby incorporatedby reference in its entirety.

BACKGROUND

Multi-functional mobile communication devices have become standarddevices carried by users. As mobile technology continues to progressmobile devices are commonly equipped with digital image capabilities.Mobile communication devices are increasingly capable of connecting toother devices over a network. The ubiquity of such devices provides anopportunity to utilize the devices to perform transactions thatpreviously were limited to private networks. It is with respect to thisgeneral environment that embodiments of the present disclosure have beencontemplated.

SUMMARY

Embodiments of the present disclosure relate to using mobilecommunication devices to complete transactions in person-to-person,person-to-business, and business-to-business transactions. Thetransactions may be performed by a human interacting with a device ortwo or more devices interacting with each other. In embodiments, thetransactions may be financial transactions; however, other types oftransactions may be performed using the systems and methods disclosedherein. In embodiments, an application on the mobile device may becapable of reading and processing a secure image, such as a SecureTransaction Image (STI) or Payment Data Image (PDI) code, modifying andstoring information associated with the secure image, and completing atransaction using the secure image.

The embodiments disclosed herein may be utilized to transfer fundsbetween two parties without relying upon the current credit/debit cardtransaction networks. For example, the embodiments disclosed hereinallow users to securely complete financial transactions over an opennetwork, such as, but not limited to, the Internet. This allows partiesto complete financial transactions without reliance upon credit anddebit cards.

In one embodiment, systems and methods are provided that may be used toinitiate a transaction. For example, a method performed by a payee, ormerchant, device may begin a transaction by receiving transactiondetails and initiating the creation of a secure image. In embodiments,the secure image may be created by a remote device, such as a server,communicating with the device. Upon receiving the secure image from theserver, the device may make the secure image available to one or moreother devices participating in a transaction. The secure image may beprovided to one or more other devices by displaying the secure image orby sending the secure image in an electronic message.

In other embodiments, systems and methods are provided that may be usedto complete a transaction. For example, a method performed by a payor,or customer, device may initiate the completion of a transaction byreceiving the secure image from a payee device. The device may receivethe secure image by capturing a copy of a displayed secure image using acamera or scanner. The device may also receive the secure image in anelectronic message. The received secure image may then be provided to aremote device, such as a server communicating with the device, as acandidate image. Upon verification of the candidate image, the devicereceives the transaction details which can be modified by a user priorto confirming the transaction. The device can then receive aconfirmation by the user and provide the confirmation to one or moreremote devices.

Additional embodiments provide systems and methods for facilitating atransaction between two parties. A device may receive transactiondetails and a request to create a secure image. In response to receivingthe request, the device may create the secure image and associate itwith a transaction and/or transaction details. The secure image may thenbe provided to one or more devices that are participating in thetransaction. At a later time, the device may receive a candidate image.The device may verify the candidate image to determine that it is asecure image associated with a transaction and/or transaction data. Thetransaction data may be provided to one or more devices. The device maythen receive a confirmation of the transaction and take any actionsnecessary to complete the transaction.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter.

BRIEF DESCRIPTION OF THE DRAWINGS

The same number represents the same element or same type of element inall drawings.

FIG. 1 is an embodiment of a system 100 that may be employed to performa transaction using a secure image.

FIG. 2 is an embodiment of a flow chart illustrating a method 200 forregistering entities and devices with a core transaction engine.

FIG. 3 is an embodiment of a flow chart illustrating a method 300 forinitiating a transaction using a device.

FIG. 4 is a flowchart illustrating an embodiment of a method 400 forimplementing a user interface for a payee device.

FIG. 5 is an embodiment of an exemplary transaction details form 500.

FIG. 6 is an exemplary embodiment of screenshot of a secure imagedisplay 600.

FIG. 7 is an exemplary embodiment of a send screen 700.

FIG. 8 is an embodiment of an exemplary transaction status screen 800.

FIG. 9 is flowchart illustrating an embodiment of a method 900 that maybe employed by a device to complete a transaction.

FIG. 10 is a flowchart illustrating an embodiment of a method 1000 forimplementing a user interface for a device to complete a transaction.

FIG. 11 is an exemplary embodiment of a user interface 1100 that may beused to capture a secure image.

FIG. 12 is an exemplary embodiment of a transaction details screen 1200that displays transaction details for completing a transaction.

FIG. 13 is an embodiment of an exemplary transaction status screen 1300.

FIG. 14 is a flowchart illustrating an embodiment of a method 1400 forresponding to a request to initiate a transaction.

FIG. 15 is a flow chart illustrating an embodiment of a method 1500 forresponding to a request to complete a transaction.

FIG. 16 is an embodiment of a method 1600 for performing a method ofcreating a secure image.

FIG. 17 is an embodiment of a computing environment for implementing thevarious embodiments described herein.

DETAILED DESCRIPTION

Embodiments of the present disclosure relate to using mobilecommunication devices to complete transactions in person-to-person,person-to-business, and business-to-business transactions. Thetransactions may be performed by a human interacting with a device ortwo or more devices interacting with each other. For example, thetransactions disclosed herein may be accomplished through human/machineinteraction, machine/machine interaction, etc. In embodiments, thetransactions may be financial transactions; however, other types oftransactions may be performed using the systems and methods disclosedherein. In embodiments, an application on the mobile device may becapable of reading and processing a secure image, such as a SecureTransaction Image (STI) or PDI code, modifying and storing informationassociated with the secure image, and completing a transaction using thesecure image.

The embodiments disclosed herein may be utilized to transfer fundsbetween two parties without relying upon the current credit/debit cardtransaction networks. For example, the embodiments disclosed hereinallow users to securely complete financial transactions over a network,including an open network, such as, but not limited to, the Internet.This allows parties to complete financial transactions without relianceupon credit and debit cards and without exposing potentially sensitivefinancial information.

The systems and methods disclosed herein provide for affordable andscalable solutions to establish local, national, and internationaltransaction processing networks. In embodiments related to the financialsector, the systems and methods disclosed herein may be used toestablish payment processing networks by connecting financialinstitutions directly with consumers and customers via an open networkconnection, such as the Internet. Mobile device operated by the usersmay connect to the network and perform financial transactions withoutreliance upon current credit and debit card networks.

In embodiments, security may be maintained by using a secure image toidentify transactions and transaction details. A secure image mayuniquely identify a transaction and/or transaction details withoutexposing any sensitive user information, such as user financialinformation. In embodiments, participants in the transaction mayinitiate and complete the transaction using a secure image, therebysecuring the transaction and obscuring sensitive information frominterference and/or interception by an unauthorized party.

FIG. 1 is an embodiment of a system 100 that may be employed to performa transaction using a secure image. For ease of discussion, thefollowing discussion is described as performing a financial transaction.However, one of skill in the art will appreciate that other types oftransactions may be performed using the system 100. In embodiments, aparty to a transaction may register with a trusted server, such as oneor more servers that form a transaction core 110. In embodiments,registration may include creating an account with the trusted server.The account may be associated with data about the party associated withthe account. In embodiments, data may include information such as, butnot limited to, user name, first name, middle name, last name, address,mobile device information, one or more phone numbers, one or more emailaddresses, checking account details, savings account details, creditand/or debit card information, or any other information related to aparty. A first party to a transaction 102 (e.g., a payee) initiates atransaction with a second party 104 (e.g., a payor). A payee device 106receives transaction details via user 102 interaction with a graphicaluser interface (GUI). In embodiments, a payee device 106 may be a mobiledevice, a smart phone, a tablet computer, a cell phone, a laptop, acomputer, or any other type of general computing device, such asdescribed with respect to FIG. 17. In embodiments, any device capable ofan Internet or network connection and the ability to display and/orcapture a secure image may be utilized as part of the systems and/ormethods disclosed herein. Upon receipt of the transaction details, payeedevice 106 sends transaction details to a transaction core engine 110via a network (not shown). In embodiments, a network may be a cellularnetwork, a WiFi network, a POTS network, a WAN, a LAN, the Internet, orany other type of network. In embodiments, transaction core engine 110may comprise one or more servers and/or computing devices capable ofreceiving and processing data related to a transaction. In embodiments,upon receiving the transaction details, transaction core engine 110creates a unique, secure image that may be used to securely identify thetransaction and/or transaction details. In embodiments, the transactioncore engine 110 may store the transaction details and associate thesecure image with the transaction details, thereby providing for theidentification of transaction details with the secure image.

The transaction core engine 110 may then provide the secure image topayee device 106. Upon receiving the secure image, the payee device mayprovide the secure image to a payor device 108. For example, the payeedevice may send the secure image in an electronic message or display thesecure image in a manner that allows the payor device to capture thesecure image. In embodiments, a payor device 108 may be a mobile device,a smart phone, a tablet computer, a cell phone, a laptop, a computer, orany other type of general computing device as described with respect toFIG. 17. The payor device 108 may communicate with the payee device 104and transaction core engine 110 via a network. In one embodiment, thepayor device 108 may obtain the secure image by capturing a visualdisplay of the secure image on the payee device 106. For example, thepayor device 108 may capture the image using a camera or scanner that ispart of or otherwise connected to the payor device 108. In otherembodiments, the payee device 106 may transfer the secure image to thepayor device 108 in a message sent over a network. Alternatively, payeedevice 106 may direct core engine 110 to send the secure image to payordevice 106 or to another device where it can be accessed by the payordevice 106. For example, the secure image may be transferred via email,SMS message, MMS message, push notification, or via any other type ofmessage capable of being communicated between the payee device 106, thepayor device 108, and/or core engine 110.

Upon receiving the secure image, the payor device 108 may submit thesecure image to the transaction core engine 110. In embodiments, thesecure image may be compressed and encrypted before sending the secureimage to the transaction core engine 110. Compressing and encrypting thesecure image prior to sending the secure image to the transaction coreengine 110 may provide additional security to the transaction process.In embodiments, the transaction core engine 110 may identify thetransaction between the payee 102 and payor 108 using the secure image.In embodiments, upon receiving the secure image, the transaction coreengine 110 validates the secure image and, upon successful validation,returns transaction details to the payor device 106. The payor device106 may then modify transaction details and send a confirmation tocomplete the transaction to the transaction core engine 110. Uponreceiving the confirmation, the transaction core engine may confirm thatthe device sending the confirmation is authorized to confirmtransactions. If the device is authorized, the transaction core engine110 may perform the actions necessary to complete the transaction. Inembodiments related to financial transactions, the transaction coreengine 110 may send a request to the payor's financial institutionsystem 114 to debit the payor's account and transfer funds to thepayee's account. The transaction core engine 110 may also send themessage to the payee's financial institution system 112 to credit thepayee's account with the transferred funds. The communication betweenthe transaction core engine 110, the payee financial institution 112,and the payor financial institution 114 allows for a real-time transferof funds without relying upon credit and/or debit card networks. Inembodiments, financial institutions 112 and 114 are part of a network ofregistered financial institutions with the system 100. Registeredfinancial institutions may have additional benefits such as performingreal-time deposits and credits of accounts. In other embodiments, thetransaction core 110 may capture and transmit data to an ACH network(e.g., the Fed) for users who are not part of a network of registeredfinancial institutions. Having described the operating system 100, thedisclosure will now provide further detail with respect to the operationof different components of the system 100.

In embodiments, before participating in a transaction a user willregister with an embodiment of the systems disclosed herein. Forexample, a user may register and create an account with the transactioncore. FIG. 2 is an embodiment of a method 200 for registering a userwith a transaction system. In embodiments, the method 200 may beperformed by a secure server. For example, a server that is part of thetransaction core 110 (FIG. 1) may perform the method 200. Flow begins atoperation 202, where a request to create an account is received. Uponreceiving the request, a check may be performed to ensure that the userreceiving the request does not already have an account.

If the user does not have an account, flow continues to operation 204.At operation 204, user information is received. For example, informationsuch as, but not limited to, a user name, first name, middle name, lastname, address, phone number, email address, preferred method of contact,or any other information related to the user. In embodiments, financialinformation related to one or more user financial accounts may also bereceived at operation 204. Financial information may include, but is notlimited to, information (such as account number(s)) about a user'schecking account, savings account, credit card, debit card, etc. Inembodiments, this information may be securely stored on the server andassociated with the user account. In further embodiments, one or moredevices may be registered with a user account. For example, the user mayregister one or more personal computers, tablets, laptops, smartphones,etc. In embodiments, the registration of one or more devices addsadditional fraud prevention measures by limiting the performance oftransactions to the one or more devices registered for the user account.Collecting this information at registration and storing it on the serverallows for financial transactions to be completed without having to sendsensitive financial information during the transaction process. Thisprovides additional protection by maintaining sensitive information in aprotected area.

After receiving user information at operation 204, flow continues tooperation 206, where an account for the user is created. In embodiments,creating the account may include creation of a unique identifier for theuser's account. Flow continues to operation 206 where the user's accountand information is stored on the secure, trusted server. As noted above,storing user information at the secure server provides additionalsecurity by allowing transactions to complete without sending sensitiveinformation, thereby removing the chance of a third party interceptingthe sensitive information. As will be clearer from the followingdiscussion, the registration process and storage of the user informationprovides the ability to associate a secure image with transactioninformation and not user information, thereby allowing the completion oftransactions without exposing sensitive information.

FIG. 3 is an embodiment of a flow chart illustrating a method 300 forinitiating a transaction using a device such as, for example, payeedevice 106 in FIG. 1. In embodiments, a device may be a smart phone, atablet, a laptop, a computer, a television, an automated teller machine(ATM), a network connected kiosk, a merchant point-of-sale (POS)terminal, or any type of general purpose computing device as describedwith respect to FIG. 17. In one embodiment, the method 300 may beperformed by an application executing on the device. In anotherembodiment, the method 300 may be performed by a remote applicationexecuting on a remote device. In such embodiments, the device may accessthe remote application over a network, such as, but not limited to, theInternet. Flow begins at operation 302 where transaction details arereceived. In one embodiment, transaction details may be entered into thepayee device by a user. In other embodiments, the transaction detailsmay be retrieved from local storage on the payee device or may beretrieved from a remote device connected to the payee device over anetwork. The transaction details may also be received at the payeedevice from another application running on the payee device or anotherdevice (such as a point-of-sale application for a merchant payee). Infurther embodiments, the transaction details received at operation 302may be retrieved by a combination of receiving user input, retrievingdetails from local device storage, and/or retrieving information from aremote device.

In embodiments, transaction details may include any type of data relatedto the transaction. For example, in the described embodiment where thetransaction relates to a financial transaction or payment, thetransaction details may include, but are not limited to, a transactionreference identifier, a name, an address, a phone number, an emailaddress, an invoice amount, identification of a financial accountregistered for the payee with the transaction core engine, a descriptionof the transaction, an IP address, a URL, or any other type of datarelated to the transaction. One of skill in the art will appreciate thatthe method 300 may be practiced in situations or transactions other thanthose related to a payment. In such situations, any type of informationrelated to the situation or transaction may be received by a device atoperation 302.

Flow continues to operation 304 where the creation of a secure image isinitiated. In embodiments, a secure image is a unique image thatrepresents a transaction and/or transaction details. In embodiments, asecure image may be a grid based optical representation of encoded andencrypted transaction information. In other embodiments, a secure imagemay be a series of concentric circles arranged as an imagerepresentation of encoded and encrypted transaction data. In a furtherembodiment, the secure image may be one or more graphicalrepresentations, such as, but not limited to, the graphical imagespreviously described, superimposed or interlaced with a user selected oruser uploaded image (e.g., an image uploaded upon registration, such asthe registration described with respect to FIG. 2). In such embodiments,the user selected or user uploaded image may be used as the basis forproviding the user with verification of a connection to an authentic, orotherwise verified, secure server. As such, the user selected oruploaded image may then be used to store secure transaction data and maybe transmitted to a secure server (e.g., transaction core engine 110 inFIG. 1) for processing and verification. In other embodiments, thesecure image may be a photo, a bar code, or any other unique graphicthat can be used to securely identify a transaction and/or transactiondetails. In further embodiments, a secure image may have a set lifetime.In such embodiments, the transaction represented by the secure image maynot be completed after the expiration of the secure image.

In one embodiment, initiation 304 or creation of a secure image maycomprise sending a message to a remote device, such as the transactioncore engine 110 in FIG. 1, over a network, such as, but not limited to,the Internet, requesting the creation of a secure image. In suchembodiments, a device performing the method 300 (e.g., a payee device)may send the transaction details collected at operation 302, e.g.,inputted by a user or generated by another device, along with a requestto create a secure image to the remote device. In such embodiments, theremote device may process the transaction details and create the secureimage, which may then be provided to the device initiating the creationof the secure image at operation 304. In an alternate embodiment,creation of the secure image may be performed by the device performingthe method 300. In such embodiments, the secure image may then beprovided to a remote device, such as a transaction core engine, upon thecreation of the secure image at operation 304.

After initiating the creation of the secure image at operation 304, flowcontinues to operation 306 where the secure image is provided. Inembodiments, providing the secure image may include making the secureimage available to another device or application that is participatingin the transaction. For example, providing the secure image at operation306 may include making the secure image available to a device used by apayor participating in the transaction, such as payor device 104 inFIG. 1. In one embodiment, providing the secure image may includedisplaying the secure image on the device performing the method 300. Insuch embodiments, providing the secure image may include visuallydisplaying the secure image in a way that allows another device tophotograph, scan, or otherwise capture the visual display of the secureimage. In a related embodiment, the secure image may be printed onpaper, for example, provided on a bill or receipt at operation 306.Another device participating the transaction may photograph, scan, orotherwise capture the printed representation of the secure image.

In alternate embodiments, providing the secure image at operation 306may include sending the secure image to another device participating inthe transaction, such as, for example, a payor device. In suchembodiments, the device performing the method 300 may directly send theimage to the other participating device as an attachment to an email, asa SMS message, as a MMS message, push notification, or using any othertype of message or means of communication supported by the devicesparticipating in the transaction. In a related embodiment, the secureimage may be provided by a remote device at operation 306. For example,in the described embodiments in which the secure image is created by, orprovided to, a remote device, the device performing the method 300 mayinstruct the remote device to push, or otherwise provide, the secureimage to another device, or devices, involved in the transaction. Assuch, providing the secure image may include instructing a remote deviceto deliver the secure image to one or more different remote devices.Although specific examples of providing a secure image have beendescribed herein, one of skill in the art will appreciate that anymethod of providing an image to another device may be employed with theembodiments disclosed herein.

After providing the device, flow continues to operation 308 where thedevice performing the method 300 receives transaction statusinformation. In embodiments, the transaction status information mayinclude any information describing the transaction and may include anindication of whether the transaction was successfully completed. Forexample, the transaction status information may indicate that thetransaction: was successfully completed, the transaction was notsuccessfully completed, or may provide another indication. For example,in a financial transaction, an indication of whether the payor waspreapproved to perform the transaction may be received at operation 308.

FIG. 4 is a flowchart illustrating an embodiment of a method 400 forimplementing a user interface for a payee device, such as payee device106 in FIG. 1. In embodiments, a device may be a smart phone, a tablet,a laptop, a computer, a television, and ATM, network connected kiosk, aPOS terminal, or any type of general purpose computing device, includingas described with respect to FIG. 17. In one embodiment, the method 400may be performed by an application executing on the device. In anotherembodiment, the method 400 may be performed by a remote applicationexecuting on a remote device. In such embodiments, the device may accessthe remote application over a network, such as, but not limited to, theInternet. In embodiments, the method 400 may be employed to generate auser interface for an application used to initiate a transaction, forexample, by performing the method 300 described in FIG. 3. For the sakeof illustration, the method 400 is described with reference to theexemplary embodiments of user interface screenshots provided in FIGS.5-8.

Flow begins at operation 402 where a transaction details form isdisplayed. In embodiments, the transaction details form provides one ormore fields in which a user can provide information about thetransaction. In embodiments, transaction details may include any type ofdata related to the transaction. For example, in the describedembodiment where the transaction relates to a payment, the transactiondetails may include, but are not limited to, a name, an address, a phonenumber, an email address, an invoice amount, the identity of an accountfor the payee, a description of the transaction, an IP address, a URL,or any other type of data related to the transaction. One of skill inthe art will appreciate that the method 400 may be practiced insituations or transactions other than those related to a payment. Insuch situations, any type of information related to the situation ortransaction may be received by a device at operation 402. In suchembodiments, other types of fields may be displayed on the transactionscreen.

In embodiments, the transaction details form provides one or more inputareas in which a user can enter transaction information. The one or moreinput areas may be text boxes, radio buttons, drop down menus, or anyother type of graphical input field known to the art. In one embodiment,one or more fields may be prepopulated with data. For example, storedinformation about a payee (such as information received duringregistration) may be prepopulated in one or more data fields.

Flow continues to operation 404 where the device performing the method400 receives input related to transaction details. In one embodiment,the input is received by a user interacting with the one or more inputareas provided on the transaction details form. For example, a userinteracting with the user interface may enter information into textboxes, select one or more buttons, and/or select information from a dropdown menu. In other embodiments, the input areas may be populated fromdata received from a data store that is accessible to the device or maybe populated by another application. The data store may be a local datastore or a remote data store. In embodiments where the data is receivedfrom a data store or another application, the user may have the abilityto change the received data.

FIG. 5 is an embodiment of an exemplary transaction details form 500that may be displayed and interacted with as discussed in operations 402and 404. The exemplary transaction details form displayed in FIG. 5 isfrom an example application running on a mobile device. One of skill inthe art, however, will appreciate that any type of application maydisplay a transaction details form 500 regardless of the device orenvironment the application operates in. The exemplary transactiondetails form 500 includes three input areas 502, 504, and 506. Forexample, input area 502 is a text input field which corresponds to apayment amount for a transaction. Input area 504 is a drop down menuwhich allows a user to select an account that the payment may bedeposited into. In embodiments, a user may have one or more accounts atone or more financial institutions. For example, a user may have achecking account and a savings account at a bank and another savingsaccount at a credit union. In embodiments, the different user accountsmay be stored with user data and populate a drop down menu, therebyallowing a user to easily select a specific account for the payment tobe deposited. Exemplary transaction details form 500 also contains amemo field 502 in which additional notes about a transaction may beentered.

Once data has been received in the transaction details form, data store,and/or another application, flow continues to operation 406 where acommand is received to initiate the generation of a secure image. In oneembodiment, the command may be received by a user interacting with abutton that initiates the creation of the secure image.

Once the one or more input areas of transaction details form 500 havebeen populated, a user may activate create secure image button 508.Activating create secure image button 508 may cause the application toinitiate the creation of a secure image as discussed in the embodimentsdescribed with respect to FIG. 3. In embodiments, some of the inputareas may require data while others may be left unpopulated. In suchembodiments, an application may require the user to enter the requiredinformation before initiating the creation of a secure image. Forexample, in such embodiments, the create a secure image button 508 maybe disabled until all required information is provided to the one ormore input areas of transaction detail form 500. In an alternateembodiment, if a user activates the create a secure image button 508prior to entering required transaction details, a message may bedisplayed prompting the user to enter the missing required information.In embodiments, a cancel transaction button 510 may also be providedwith transaction details form 500. Activation of the cancel transactionbutton 510 may allow a user to cancel the transaction.

Returning to FIG. 4, upon receiving a command to initiate the generationof a secure image, flow continues to operation 408 where a secure imageis displayed. In one embodiment, a secure image may be displayed on thescreen of a device performing the method 400. Displaying the secureimage on the device screen allows for another device participating inthe transaction to capture the secure image, for example, by using acamera. FIG. 6 is an exemplary embodiment of a screenshot of a secureimage display 600. In embodiments, secure image display 600 may includea display area 602 that may be used to display the secure image, such asthe example secure image displayed in FIG. 6. In embodiments, thedisplay area 602 is large enough to display the entire secure image.

Under some circumstances, displaying the secure image may be sufficientto provide the secure image to another device. For example, anotherdevice participating in the transaction may capture the displayed secureimage using a camera. In such situations, a user may select the Finishbutton 604 to close the secure image display 600 after the other devicecaptures the secure image. However, in some instances, the display ofthe secure image may not be sufficient to provide the secure image toanother device. In such circumstances, the secure image display 600 mayprovide a Send Payment Image button 606. As will be discussed in furtherdetail, the Send Payment Image button 606 initiates a user interfacethat allows for the sending of a secure image.

Returning again to FIG. 4, in some embodiments, displaying the secureimage at operation 408 may be sufficient to provide the secure image toanother device. However, in some circumstances the display of the secureimage may not be enough. For example, if the other device participatingdoes not have a camera or is not located within proximity of the deviceperforming the method 400. In such situations, other means of providingthe secure image may be provided. Flow continues to operation 410 wherea command to send the secure image is received. For example, a user mayactivate a button, such as the Send Payment Image button 606 displayedin FIG. 6 thereby causing the receipt of a command to send the secureimage. Flow continues to operation 412 where a send screen is displayed.In embodiments, the send screen allows a user to select a deliverymethod to provide the secure image to another device. For example, thesend screen may provide the user with the option to deliver the secureimage to another device in an email, a SMS message, an MMS message, pushnotification, or by any other delivery method known to the art. Inadditional embodiments, the send screen may provide the user the optionto have the secure image delivered by a remote device. For example, inembodiments where the secure image is created by a server, such as atransaction core engine 110 from FIG. 1, the send screen may provide agraphical user interface (GUI) element that allows for the sending ofthe secure image by the remote device. For example, the GUI element mayallow a user to select a push method of delivery for the secure image.If a push method of delivery is selected, the secure image may beprovided to one or more devices involved in the transaction via a remotedevice.

One of skill in the art will appreciate that sending the secure imagemay be performed at different steps during the methods disclosed herein.For example, the payee device may provide the send instruction at thetime the secure image is created too. In such embodiments the secureimage may never come back to the payee device. Rather, it would be sentto the payor device, which would potentially capture it with a localapplication on the payor device and use it to complete the transaction.In other embodiments, the instruction could be to mail an invoice(physical or email) with the image on it.

In embodiments, the send screen may provide one or more graphical userinterface (GUI) elements that allow the user to select a deliverymethod. In additional embodiments, the send screen may provide one ormore input areas that allow a user to enter delivery information. Forexample, the input fields may be used to enter an email address, a phonenumber, an IP address, or any other type of contact information that maybe used to deliver the secure image.

Upon displaying the send secure image screen, flow continues tooperation 414 where input related to sending the secure image isreceived. For example, the input may be received by a user selecting oneor more delivery methods and providing contact information in the sendscreen. FIG. 7 is an exemplary embodiment of a send screen 700 that maybe displayed at operation 412 and used to receive send input atoperation 414. In embodiments, the send screen 700 includes one or morebuttons that allow a user to select a delivery method. For example,buttons 702 and 704 allow a user to select delivery of a secure imagevia email or push notification, respectively. Send screen 700 maydisplay additional input fields in which a user may provide contactinformation used for delivery of the secure image. For example, textboxes 706 and 708 may be used to receive contact information such as arecipient's name and email address. This contact information may be usedto deliver the secure image. In embodiments, upon receiving the sendinformation through, for example, the displayed GUI elements, the sendscreen 700 may display buttons that may be activated to send the secureimage (button 710) or to cancel the send operation (button 712). Inembodiments, some or all of the information may be prepopulated withcontact information from a data store, such as, for example, a contactslist or transaction history, accessible to a device or applicationperforming the method 400. For example, the information may be providedfrom information collected during a registration process.

Returning to FIG. 4, in embodiments flow continues to operation 416where transaction status information is displayed. For example, atoperation 416 an indication of the success or failure of the transactionmay be displayed. In embodiments, information about the transaction maybe displayed along with the status indication at operation 416. In otherembodiments, the indication may be provided in a pop-up window, aflowing window, or by using any other graphical feature to highlight thestatus of the transaction. For example, FIG. 8 is an embodiment of anexemplary transaction status screen 800. The exemplary transactionscreen displays the transaction status in a floating window with theunderlying window greyed out, thereby drawing the user's attention tothe status of the transaction.

Turning now to the operation of payor device in a transaction, FIG. 9 isan embodiment of a method 900 that may be employed by a device, such aspayor device 108 from FIG. 1, to complete a transaction. In embodiments,a device performing the method 900 may be a smart phone, a tablet, alaptop, a computer, a television, or any type of general purposecomputing device, such as described with respect to FIG. 17. In oneembodiment, the method 900 may be performed by an application executingon the device. In another embodiment, the method 900 may be performed bya remote application executing on a remote device. In such embodiments,the device may access the remote application over a network, such as,but not limited to, the Internet. Flow begins at operation 902 where asecure image is received. In one embodiment, the secure image may bereceived by capturing the secure image using a camera, scanner, or otherinput. For example, the device performing the method 900 may take apicture of a secure image displayed on another device in thetransaction, such as a payee device displaying a secure image. Inrelated embodiments, the secure image may be received by scanning asecure image from a bill, invoice, receipt, or other physical copy. Inalternate embodiments, the secure image may be received over a networkconnection. For example, the secure image may be received in an email,in a link included in a SMS message, in an MMS message, or in any othertype of message.

Upon receiving the secure image, flow continues to operation 904 wherethe secure image is provided to a server. In embodiments, the secureimage represents a transaction. The transaction and transaction detailsare securely encrypted by transmitting the secure image rather than thetransaction details itself. In embodiments, the security level of thetransaction may be further increased if the user devices participatingin the transaction (e.g., the payee and payor devices) are not capableof decoding the transaction information represented by the secure image.As such, security is increased if a remote, trusted server (e.g., atransaction core server) is used to both create and decode the secureimage used in the transaction. As such, in embodiments, the secure imagereceived by the device at operation 902 may be transmitted to a remoteserver for processing. In one embodiment, the secure image may betransmitted as it was captured or received at operation 902. In otherembodiments, the secure image captured or received by the device atoperation 902 may be compressed and/or encrypted prior to transmissionto a remote server for processing (such as transaction core engine 110in FIG. 1). Upon sending the secure image, flow continues to operation906 the application and/or device performing the method 900 receivestransaction details. For example, once the remote server processes thesecure image, the actual details of the transaction may be returned tothe device that provided the secure image. In embodiments, thetransaction details may be encrypted. In such embodiments, the devicemay decrypt the transaction details upon receiving the information atoperation 906. For example, an application running on the payor or payeedevice may be adapted to participate in an encryption algorithm sharedwith a core transaction server. Once the transaction details arereceived and decrypted, if necessary, the device performing the method900 may display the transaction details to a user. In embodiments, theuser may optionally modify, amend or augment the transaction detailsoriginally provided by the transaction initiator (e.g., payee). Forexample, a payor specific description or gratuity may be added to thetransaction details. In such embodiments, flow continues to optionoperation 908 where the device receives modifications to the transactiondetails. At operation 908, the device may perform the modifications onthe transaction details by modifying, amending, and/or augmenting thetransaction details.

Flow continues to operation 910 where confirmation of the transaction(and any modification to the transaction) is sent to the server. Forexample, upon reviewing and optionally modifying the transactiondetails, a transaction may be confirmed, for example, by authorizingpayment. The confirmation may be sent to a trusted server, such as, forexample, a core transaction engine, to complete the transaction byinitiating the transfer of funds from a payor's account to a payee'saccount. In embodiments, sending the confirmation at operation 910 maycomplete the payor's role in the transaction. Although not shown, uponsending the confirmation at operation 910, the application and/or deviceperforming the method may receive a confirmation indicating the statusof the transaction.

The embodiment described above provides a secure method to providepayment from one party to another using an open network, such as theInternet. The secure image provides security for the transaction byidentifying transactions in a manner that may only be deciphered by oneor more trusted servers, such as a transaction core 110 from FIG. 1. Assuch, the use of a secure image may prevent or otherwise limit theexposure of sensitive user identity and/or transaction information. Inembodiments, even the payor device and payee device involved in thetransaction may not be able to process the secure image. The secureimage may represent a particular transaction between two parties. Assuch, any funds transferred using the secure image may only betransferred between the parties involved in the transaction. As such,the secure image may act as a secure identifier that may be transmittedover an open network, such as the Internet, without compromisingsecurity of the parties involved in the transaction, even if the secureimage is intercepted by an unauthorized party because the unauthorizedparty will not be able to decipher any of the transaction details fromthe secure image alone. Furthermore, even if an unauthorized party coulddecipher the transaction details from the secure image, the third partywould only intercept information related to the transaction, all of theparties' information would remain safe. If the unauthorized partysupplies the secure image to a trusted server (such as a transactioncore engine), the trusted server may determine that the device providingthe secure image is not an authorized device and will not complete thetransaction. However, even if the trusted sever determines that thedevice providing the secure image is authorized to complete thetransaction, an unauthorized third party cannot intercept funds from thetransaction because the secure image may be tied to the two authorizeddevices (and the payor and payee who registered such devices) involvedin the transaction.

In embodiments, the secure image may also have a limited lifespan. Forexample, the secure image may include a timestamp that may be used todetermine when the secure image expires. In other embodiments, a devicethat created the secure image, such as a secure server, may storelifetime information for the secure image upon its creation. Thelifetime associated with the secure image may provide additionalsecurity against use of the image by an unauthorized party. For example,even if an unauthorized third party obtained a copy of a transactionimage, the image would expire either (a) by virtue of the fact it hasalready been processed or (b) as a result of a predetermined expirationtime, and would not be functional for any future unauthorized use by thethird party.

FIG. 10 is a flowchart illustrating an embodiment of a method 1000 forimplementing a user interface for a payor device, such as payor device108 in FIG. 1. In embodiments, a device may be a smart phone, a tablet,a laptop, a computer, a television, an ATM, a network connected kiosk, aPOS terminal, or any type of general purpose computing device, such asdescribed with respect to FIG. 17. In one embodiment, the method 1000may be performed by an application executing on the device. In anotherembodiment, the method 1000 may be performed by a remote applicationexecuting on a remote device. In such embodiments, the device may accessthe remote application over a network, such as, but not limited to, theInternet. In embodiments, the method 1000 may be employed to generate auser interface for an application used to initiate a transaction, forexample, by performing the method 900 described in FIG. 9. For the sakeof illustration, the method 1000 is described with reference to theexemplary embodiments of user interface screenshots provided in FIGS.11-13.

Flow begins at operation 1002 where a command is received to capture asecure image. In one embodiment, the command to capture the secure imagemay be received by a user directing the application to retrieve thesecure image from an email, a SMS message, a MMS message, or any othertype of message. In further embodiments, the input secure image may bepushed to the device performing the method 1000. In such embodiments,the push notification may include a command that, when received by thepayor device, causes the payor device to capture the secure image atoperation 1002. In embodiments where the secure image may be capturedfrom the display of another device or from a print out of the secureimage, receiving the command to capture the image at operation 1002 mayinclude an instruction to capture the image using a camera, scanner, orother means of input of the device. In embodiments where the secureimage is captured using, for example, a camera or scanner, the capturedsecure image may be automatically transmitted to a trusted serverwithout requiring additional input from the user to send the secureimage. In such embodiments, upon transferring the captured secure imageto the server, the captured secure image may be removed from memory ofthe device that captured the secure image. In embodiments, the capturedsecure image may be compressed and/or encrypted prior to transferringthe captured secure image to the server. One of skill in the art willappreciate that any type of compress and/or encryption may be employedwith the embodiments disclosed herein. The automatic sending and removalof the secure image by the device may increase security by making thesecure image inaccessible to other applications on the device, therebyrestricting the transfer of the secure image between applications anddevices.

FIG. 11 is an exemplary embodiment of a user interface 1100 that may beused to capture a secure image. In the exemplary embodiment, a secureimage may be captured from the display of another device or from a printout of the secure image using a camera. The user interface 1100 mayinclude a target area which may help the user line up and capture apicture of secure image. In embodiments, upon lining up the secure imagewithin the target area, the user may cause capture the image with thecamera by activating the “Capture” button. In other embodiments, adevice may be able to automatically capture the secure image using acamera or other input upon recognizing the secure image. As previouslydescribed, upon capturing the image, the secure image may automaticallybe sent to a trusted server and then removed from the capturing device.

Returning to FIG. 10, flow continues to operation 1004 where the userinterface displays the transaction details. As described in embodimentsdisclosed herein, upon providing a secure image to a trusted server,such as the transaction core, the trusted server may return thetransaction details to the device. The received transaction details maybe displayed at operation 1004. In embodiments, transaction details mayinclude any type of data related to the transaction. For example, in thedescribed embodiment where the transaction relates to a payment, thetransaction details may include, but are not limited to, a name, anaddress, a phone number, an email address, an invoice amount, agratuities amount, deposit instructions containing an American BankingAssociation number (ABA) for routing, an account number, a descriptionof the transaction, an IP address, a URL, or any other type of datarelated to the transaction. One of skill in the art will appreciate thatthe method 1000 may be practiced in situations or transactions otherthan those related to a payment. In such situations, any type ofinformation related to the situation or transaction may be displayed bya device at operation 1004. In such embodiments, other types of fieldsmay be displayed on the transaction screen.

In embodiments, one or more fields of the transaction details may beaugmented, amended, or otherwise modified by the user upon display atoperation 1004. For example, a user may be allowed to modify a gratuityor to insert notes about the transaction. Flow continues to optionaloperation 1006 where the application and/or device performing the method1000 received input detailing modifications to the transaction details.The input may be received from a user interacting with the elements ofthe user interface in a similar manner as described with respect to FIG.4. In other embodiments, the input may be received from a data storeand/or another application. In some embodiments, the user may berestricted from modifying certain transaction details. The userinterface provided by the method 1000 may prevent the user frommodifying some transaction details. Flow then continues to operation1008 where a confirmation to proceed with the transaction is received.In embodiments, receiving the confirmation of the transaction mayinitiate the sending of any modifications to the transaction informationas well as a command to proceed with the transaction to a trustedserver, such as the transaction core.

FIG. 12 is an exemplary embodiment of a transaction details screen 1200that presents transaction details to a user. In embodiments, transactiondetails that may not be modified may be presented in to the user, suchas the “Payment Amount” and “Payee” at the top portion 1202 of thetransaction details screen 1200. In embodiments, the transaction detailsthat cannot be modified may be displayed as static information by notincluding the transaction details in a user interface element thataccepts user input. In embodiments, as illustrated in transactiondetails screen 1200 a user completing the transaction may modify or addadditional transaction data to the transaction. In such embodiments,input areas such as text boxes, check boxes, radio buttons, drop downmenus, or any other type of graphical user interface element may beemployed with the embodiments disclosed herein. For example, a user canenter notes about a transaction in text box 1206. Furthermore, asillustrated in the exemplary embodiment of FIG. 12, a user completing atransaction may select the means in which the transaction is completed.For example, a user may associate various different accounts and/orpayment methods with their account. For example, a user may associate acredit card, a checking account, a savings account, etc. As illustratedby drop down menu 1204, a user may select which account is used to drawfunds from to complete the transaction. In embodiments, such informationis collected during the registration process and stored on a securesever. None of this information is stored on a party's device, therebyproviding additional security in case the device is lost.

After optionally modifying the transaction information, a user mayconfirm the transaction by activating the “Confirm Payment” button 1208.In embodiments, when the user activates the “Confirm Payment” button1208, any modifications made by the user may be sent to the trustedserver, such as a transaction core engine, as well as an instruction tocomplete the transaction. Although not shown, upon confirming thepayment, a user may be prompted to provide authentication to ensure thatthe user is allowed to confirm the transaction. For example, the usermay be prompted to enter a PIN, a password, or draw a pattern on adevice screen to authenticate the user. In other embodiments, voice orfacial recognition software may be employed to authenticate the user.One of skill in the art will appreciate that any type of authenticationmay be employed upon activation of the “Confirm Payment” button 1208.Furthermore, as illustrated in FIG. 12, a user may cancel thetransaction at any type by activating the “Cancel Payment” button 1210.

Returning to FIG. 10, upon completion receiving and sending the commandto confirm the transaction, information about the transaction status maybe returned. Flow proceeds to operation 1010, where the transactionstatus may be displayed. In embodiments, the transaction status may bedisplayed along with one or more of the transaction details. Forexample, at operation 1010 an indication of the success or failure ofthe transaction may be displayed. In embodiments, information about thetransaction may be displayed along with the status indication atoperation 1010. In embodiments, transaction status may be provided by asecure server, such as one or more servers in a transaction core, or bya third party server, such as a server from a financial institution. Inother embodiments, the indication may be provided in a pop-up window, aflowing window, or by using any other graphical feature to highlight thestatus of the transaction. FIG. 13 is an embodiment of an exemplarytransaction status screen 1300.

Having described the embodiments of methods that may be performed on theend user devices (e.g., the parties in a transaction, a payor/payeedevice, etc.) the disclosure now turns to the various embodiments ofmethods that may be performed by one or more trusted servers, such asthe transaction core engine 110 described in FIG. 1. In embodiments, atrusted server is a device that is accessible to the end user devicesover a network, such as, but not limited to, the Internet. Inembodiments, the one or more trusted server may store accountinformation related to the end users of a transaction. For example,before participating in a transaction, a user may have to register anaccount with trusted server. In embodiments, the trusted server maycollect information about the user. Example information includes theusers name, address, one or more account numbers, authenticationinformation, etc. The trusted server may then create an account for theuser and store the user information for use in transactions.

In addition to creating and storing accounts, the one or more trustedservers may be employed to process and/or complete transactions betweenmultiple users. In embodiments, one or more trusted servers may performdifferent roles depending on whether the server is communicating with aninitiator of a transaction (e.g., a payee) or a party completing atransaction (e.g., a payor). FIG. 14 is a flowchart illustrating anembodiment of a method 1400 for responding to a request to initiate atransaction. For example, in embodiments, method 1400 may be performedin response to receiving a request from a payee device to initiate afinancial transaction. However, while the methods disclosed herein aredescribed with reference to a financial transaction, one of skill in theart will appreciate that the method 1400 may be employed in variousdifferent situations for different types of transactions. In oneembodiment, the method 1400 may be performed by a trusted server, suchas server that is part of the transaction core engine 110 described inFIG. 1. In other embodiments, the method 1400 may be performed by one ofthe end user devices. One of skill in the art will appreciate that anytype of general computing device may be employed to perform the method1400.

Flow begins at operation 1402 where a device, such as, but not limitedto, a trusted server, receives transaction details. For example, in oneembodiment, the device may receive transaction details from an end userdevice over a network, such as, but not limited to, the Internet. In oneembodiment, the transaction details may also include a command toinitiate a transaction and create a secure image. In another embodiment,initiation of a transaction and creation of a secure image may beperformed automatically upon receiving the transaction details atoperation 1402. In a further embodiment, the transaction detailsreceived at operation 1402 may be received via user interaction with aGUI of the device performing the method 1400.

In further embodiments, a secure image may be requested via a webservice or API to a secure server, such as the one or more servers fromthe transaction core engine 110. For example, a user may generate one ormore invoices to customers via a billing platform or program thatinterfaces with a secure server (such as a transaction core engine 110)using an application programming interface (API). Through the interface,the billing platform may request the generation and sending secureimages to customers. In such embodiments, the secure images may bedelivered to the customers via an electronic invoice (e.g., anelectronic message).

Flow continues to operation 1404 where a secure image is created. Inembodiments, the secure image may be based upon the one or moretransaction details received at operation 1402. In embodiments, a secureimage is a unique image that may identify a transaction and/orrepresents the transaction details. In embodiments, the secure image maybe a series of concentric circles. In embodiments, a secure image may bea grid based optical representation of encoded and encrypted transactioninformation. In other embodiments, a secure image may be a series ofconcentric circles arranged as an image representation of encoded andencrypted transaction data. In a further embodiment, the secure imagemay be one or more graphical representations, such as, but not limitedto, the graphical images previously described, superimposed orinterlaced with a user selected or user uploaded image (e.g., an imageuploaded upon registration, such as the registration described withrespect to FIG. 2). In such embodiment, the user selected or useruploaded image may be used as the basis for providing the user withverification of a connection to an authentic, or otherwise verified,secure server. As such, the user selected or uploaded image may then beused to store secure transaction data and may be transmitted to a secureserver for processing and verification. One of skill in the art willappreciate that any type of unique image may be utilized as a secureimage to identify a transaction and represent transaction details.Creation of a secure image is described with further detail in thediscussion accompanying FIG. 16.

After creating the secure image, flow continues to operation 1406 wherethe secure image is associated with a transaction and/or one or moretransaction details. In one embodiment, the transaction and/or one ormore transaction details may be stored in a data store accessible to thedevice and/or application performing the method 1400. The secure imagemay be associated with the stored transaction information and/or one ormore transaction details. By associating the secure image with thetransaction and/or transaction details, the secure image may be used toidentify the transaction and/or transaction details at a later time. Inalternate embodiments, the secure image may be sent to a differentdevice for association with the transaction and/or transaction details.In embodiments, the secure image may also be associated with informationcaptured during registration by the parties involved in the transaction.

Flow continues to operation 1408 where the secure image is sent to oneor more devices. In one embodiment, the secure image may be returned tothe device that requested the secure image. In another embodiment, thesecure image may be sent to another device, such as, for example, apayor device. In embodiments, sending the secure image to the one ormore devices allows for the one or more devices to later identify thetransaction and/or transaction details by returning the secure image tothe device that associated the secure image with the transaction and/ortransaction information.

FIG. 15 is a flow chart illustrating an embodiment of a method 1500 forresponding to a request to complete a transaction. For example, inembodiments, method 1500 may be performed in response to receiving arequest from a payor device to complete a financial transaction.However, while the methods disclosed herein are described with referenceto a financial transaction, one of skill in the art will appreciate thatthe method 1500 may be employed in various different situations fordifferent types of transactions. In one embodiment, the method 1500 maybe performed by a trusted server, such as server that is part of thetransaction core 110 described in FIG. 1. In other embodiments, themethod 1500 may be performed by one of the end user devices. One ofskill in the art will appreciate that any type of general computingdevice may be employed to perform the method 1500.

Flow begins at operation 1502 where a candidate image is received. Inembodiments, a candidate image is an image that a device is submittingas a secure image. If the candidate image is a secure image, it may beused to identify a transaction and/or transaction details. Flowcontinues to decision operation 1504 where the candidate image isvalidated. In embodiments, validation of candidate image determineswhether the candidate image is a secure image. In one embodiment, thevalidation may be performed by matching the candidate image to a secureimage that is associated with a transaction and/or transaction details.One of skill in the art will appreciate that any type of imagevalidation may be employed at operation 1504. In further embodiments,validation of the secure image at operation 1504 may also includevalidating that the one or more parties to the transaction areregistered parties with the transaction core. In embodiments, onlyregistered parties may use the systems and methods disclosed herein.

If the candidate image is not validated, the image may be a fraud. Insuch circumstances, flow branches NO to operation 1518 and thetransaction is denied. In embodiments, a status message indicating thefailure to complete the transaction may be returned at operation 1518.At this point, method 1500 terminates. If the image is valid, then flowbranches YES to operation 1506.

At operation 1506, one or more transaction details are provided to thesender of the candidate image. In embodiments, a sender providing avalid transaction image may be identified as an authorized party to atransaction. As such, one or more transaction details may be sent to thesender at operation 1506.

Flow continues to operation 1508. At operation 1508 one or moreamendments, augmentations, and/or modifications to the transactiondetails are received in response to providing the transaction details atoperation 1506. In embodiments, upon receiving the additions and/ormodifications at operation 1508, the received details may be storedstore along with the other transaction details, such as, for example,any transaction details received during the initiation of thetransaction as described with respect to FIG. 14. In embodiments, uponreceiving any modifications, the device performing the method 1500 mayvalidate that the modifications are allowable.

Flow continues to operation 1512 where a transaction confirmation isreceived. In embodiments, the transaction confirmation may be a requestto complete the transaction as provided in the transaction details asoriginally presented or as modified. Flow continues to decisionoperation 1516 where a determination is made as to whether the deviceproviding the confirmation is authorized to complete the transaction. Inone embodiment, a determination may be performed by comparing a passwordor pin number received with the confirmation to a password stored for aparticular user. In another embodiment, the location of the device maybe used to confirm whether the user of the device is authorized tocomplete the transaction. For example, geographic location of the devicethat sent the confirmation may be compared to a known location of theauthorized user. If the geographic location differs from the knownlocation, a determination may be made that an unauthorized user isattempting to complete a transaction. In embodiments, the verificationmay be geographical. For example, if the secure image is captured by acamera, the verification may check to see that the capturing device(e.g., payor device) is in physical proximity to the display device(e.g., payee device). While specific methods of authorization aredescribed herein, one of skill in the art will appreciate than any typeof authorization may be performed at operation 1512.

If the device and/or user of the device is not authorized to confirm thetransaction then the confirmation may be an attempt at a fraudulenttransaction. In such circumstances, flow branches NO to operation 1518and the transaction is denied. In embodiments, a status messageindicating the failure to complete the transaction may be returned atoperation 1518. At this point, method 1500 terminates. If the deviceand/or user are authorized to confirm the transaction, then flowbranches YES to operation 1514.

At operation 1514 the transaction is processed. In embodiments,processing the transaction may include performing any actions necessaryto complete the transaction. For example, in a financial transaction,processing the transaction at operation 1514 may include contacting thefinancial institutions of the parties involved in the transaction. Forexample, a message may be sent to the financial institution to debit theaccount of the payor and transfer money to the account of the payee.Additionally, a message may be sent to the financial institution of thepayee to credit the account of the payee in anticipation of receiving atransfer of funds from the payor's account. In such embodiments, thetransfer of funds from the accounts may be performed in real-time. Inanother embodiment, processing the transaction may include providing apreauthorization for the payor to perform the transaction. In suchembodiments, the actual transfer of funds between the payor and payeeaccounts may be performed at a later time. While specific embodimentsrelated to financial transactions are provided herein, one of skill inthe art will appreciate that the embodiments disclosed herein are notlimited to financial transactions. In situations involving other typesof transactions, any actions necessary to complete the transaction maybe performed at operation 1514.

After processing the transaction, flow continues to operation 1516 whereone or more transaction status messages may be sent to the variousparties involved in the transaction. The transaction status may includeinformation about the transaction as well as an indication as to whetherthe transaction was successfully completed.

FIG. 16 is an embodiment of a method 1600 for performing a method ofcreating a secure image. In embodiments, a secure image is a uniqueimage that may be used to represent a transaction and/or transactiondetails. The secure image may be transferred between parties of thetransaction rather than the actual transaction or account details,thereby ensuring against an unauthorized third party from interceptingany transaction details or account information. As such, theparticipants in a transaction are assured that no sensitive informationis put at risk. Flow begins with operation 1602 where the transactiondetails are received. Flow continues to operation 1604 where, inembodiments, the transaction details are converted. In one embodiment,the transaction details may be converted to binary, octal, or hexvalues. In other embodiments, any type of conversion may be employed atoperation 1604.

Flow continues to operation 1606 where the converted transaction data isencrypted. In embodiments, the converted transaction data may beencrypted by hashing the conversion values with a reference identifier.In other embodiments, any type of encryption algorithm may be employedat operation 1606. After encrypting the data, flow continues tooperation 1608 where an image is generated based off of the encrypteddata. For example, the encrypted data may be used as input to a graphicsfunction to generate a unique, secure image. In embodiments, the imagegenerated at operation 1608 may be provided as a secure image. Inanother embodiment, the generated image may overlay or be subtractedfrom an image selected by the user. The image may be provided orselected during the registration process. Overlaying or subtracting thegenerated image on an image provided by the user provides additionalsecurity by allowing selection of a particular image for transactionsand may provide additional assurance to a user that he/she is connectedto an authenticated secure server. Additionally, allowing the user toselect the image provides additional branding benefits.

Although specific examples have been provided herein in which a payee(or payee device) initiates a financial transaction, one of skill in theart will appreciate that a payor (or payor device) may also initiate atransaction. In such embodiments, the methods for initiating atransaction described herein may be employed to collect informationrelated to a debt being paid by one party to another (as opposed to adebt being owed). In such embodiments, a payor may provide transactiondetails related to the debt being paid. A secure image may be created torepresent the payment and may be transferred to another device, such asa payee device, using the various methods of transferring secure imagesdisclosed herein. Furthermore, in such embodiments the payee would actas a party completing the transaction and performing the methods fordoing so described herein. For example, the payee device may capture thesecure image identifying the payment, submit the secure image to atrusted server, received details about the payment, and confirm thetransaction. As such, one of skill in the art will appreciate that themethods for initiating and completing a transaction disclosed herein maybe performed by either a payee device or payor device within a financialtransaction.

Furthermore, while embodiments have been described with respect toperforming financial transactions, one of skill in the art willappreciate that other types of transactions may be performed using thesystems and methods disclosed herein. Although references may be made toan action being performed by one or more parties in a transaction (e.g.,a payor or a payee or a transaction initiator), one of skill in the artwill appreciate that the functionality described herein may be performedby a device associated with the party and not the parties themselves.

With reference to FIG. 17, an embodiment of a computing environment forimplementing the various embodiments described herein includes acomputer system, such as computer system 1700. Any and all components ofthe described embodiments (such as the DVR, the content storage sever, alaptop, mobile device, personal computer, network connected kiosk, ATM,POS terminal, etc.) may execute as or on a client computer system, aserver computer system, a combination of client and server computersystems, a handheld device, and other possible computing environments orsystems described herein. As such, a basic computer system applicable toall these environments is described hereinafter.

In its most basic configuration, computer system 1700 comprises at leastone processing unit or processor 1704 and system memory 1706. The mostbasic configuration of the computer system 1700 is illustrated in FIG.17 by dashed line 1702. In some embodiments, one or more components ofthe described system are loaded into system memory 1706 and executed bythe processing unit 1704 from system memory 1706. Depending on the exactconfiguration and type of computer system 1700, system memory 1706 maybe volatile (such as RAM), non-volatile (such as ROM, flash memory,etc.), or some combination of the two.

Additionally, computer system 1700 may also have additionalfeatures/functionality. For example, computer system 1700 may includeadditional storage media 1708, such as removable and/or non-removablestorage, including, but not limited to, magnetic or optical disks ortape. In some embodiments, software or executable code and any data usedfor the described system is permanently stored in storage media 1708.Storage media 1708 includes volatile and non-volatile, removable andnon-removable media implemented in any method or technology for storageof information such as computer readable instructions, data structures,program modules, or other data.

System memory 1706 and storage media 1708 are examples of computerstorage media. Computer storage media includes, but is not limited to,RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM,digital versatile disks (DVD) or other optical storage, magneticcassettes, magnetic tape, magnetic disk storage, other magnetic storagedevices, or any other medium which is used to store the desiredinformation and which is accessed by computer system 1700 and processor1704. Any such computer storage media may be part of computer system1700. In some embodiments, system memory 1706 and/or storage media 1708may store data and/or computer executable instructions used to performthe methods or form the system(s) disclosed herein. In otherembodiments, system memory 1706 may store transaction algorithminstructions 1714 to perform the various transaction methods disclosedherein and/or secure images 1716.

Computer system 1700 may also contain communications connection(s) 810that allow the device to communicate with other devices. Communicationconnection(s) 1710 is an example of communication media. Communicationmedia may embody a modulated data signal, such as a carrier wave orother transport mechanism and includes any information delivery media,which may embody computer readable instructions, data structures,program modules, or other data in a modulated data signal. The term“modulated data signal” means a signal that has one or more of itscharacteristics set or changed in such a manner as to encode informationor a message in the data signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as an acoustic, RF,infrared, and other wireless media. In an embodiment, secure images,transaction details, commands to perform transactions, and/or request tocreate secure images may be transmitted over communicationsconnection(s) 1710.

In some embodiments, computer system 1700 also includes input and outputconnections 1712, and interfaces and peripheral devices, such as agraphical user interface. Input device(s) are also referred to as userinterface selection devices and include, but are not limited to, akeyboard, a mouse, a pen, a voice input device, a touch input device,touch screens, etc. Output device(s) are also referred to as displaysand include, but are not limited to, cathode ray tube displays, plasmascreen displays, liquid crystal screen displays, speakers, printers,etc. These devices, either individually or in combination, connected toinput and output connections 1712 are used to display the information asdescribed herein. All these devices are well known in the art and neednot be discussed at length here.

In some embodiments, the component described herein comprise suchmodules or instructions executable by computer system 1700 that may bestored on computer storage medium and other tangible mediums andtransmitted in communication media. Computer storage media includesvolatile and non-volatile, removable and non-removable media implementedin any method or technology for storage of information such as computerreadable instructions, data structures, program modules, or other data.Combinations of any of the above should also be included within thescope of readable media. In some embodiments, computer system 1700 ispart of a network that stores data in remote storage media for use bythe computer system 1700.

This disclosure described some embodiments of the present invention withreference to the accompanying drawings, in which only some of thepossible embodiments were shown. Other aspects may, however, be embodiedin many different forms and should not be construed as limited to theembodiments set forth herein. Rather, these embodiments were provided sothat this disclosure was thorough and complete and fully conveyed thescope of the possible embodiments to those skilled in the art.

Although specific embodiments were described herein, the scope of theinvention is not limited to those specific embodiments. One skilled inthe art will recognize other embodiments or improvements that are withinthe scope and spirit of the present invention. Therefore, the specificstructure, acts, or media are disclosed only as illustrativeembodiments. The scope of the invention is defined by the followingclaims and any equivalents therein.

1. A method of participating in a transaction using a first device, themethod comprising: receiving one or more transaction details for atransaction; initiating a creation of a secure image, wherein the secureimage is a unique image that represents the one or more transactiondetails; and providing the secure image to a second device.
 2. Themethod of claim 1, wherein providing the secure image to the seconddevice comprises displaying the secure image on the first device.
 3. Themethod of claim 1, wherein providing the secure image to the seconddevice comprises sending the secure image to the second device.
 4. Themethod of claim 1, wherein the first device is a payee device.
 5. Themethod of claim 1, wherein the first device is a payor device.
 6. Themethod of claim 1, wherein initiating the creation of the secure imagecomprises: sending a request to a server to create the secure image; andsending the one or more transaction details to the server.
 7. The methodof claim 1, further comprising: prior to initiating creation of thesecure image, sending user information to a transaction core engine,including financial information; wherein the secure image represents theone or more transaction details and does not represent the financialinformation.
 8. A method of participating in a transaction using adevice, the method comprising: receiving a secure image, wherein thesecure image is a unique image that represents the one or moretransaction details of a transaction; sending the secure image to atransaction core engine; in response to sending the secure image to thetransaction core engine, receiving, from the transaction core engine,the one or more transaction details; displaying the one or moretransaction details; and sending, to the transaction core engine,confirmation of the transaction.
 9. The method of claim 8, whereinreceiving the secure image comprises one of capturing the secure imageand taking a picture of the secure image.
 10. The method of claim 8,wherein receiving the secure image comprises receiving the secure imagein at least one of: an email; an SMS message; a MMS message; a pushnotification; an electronic invoice; an instant message.
 11. The methodof claim 8, further comprising prior to sending the confirmation of thetransaction, modifying the one or more transaction details.
 12. Themethod of claim 11, wherein modifying the one or more transactiondetails comprises adding gratuity.
 13. The method of claim 8, whereinthe one or more transaction details comprise at least one of: atransaction reference identifier; an invoice amount; and a gratuityamount.
 14. The method of claim 8, further comprising prior to sendingconfirmation to the server, verifying that a user of the device isauthorized to confirm the transaction.
 15. A computer readable mediumcomprising computer-executable code that, when executed by at least oneprocessor, perform a method for processing payment transactions, themethod comprising: Receiving one or more transaction details from afirst device; creating a secure image, wherein the secure image is aunique image that represents the transaction information; sending thesecure image; receiving a candidate image from a second device;determining whether the candidate image and the secure image are thesame; when the candidate image and the secure image are the same,sending the transaction details to the second device; and receiving atransaction confirmation from the second device.
 16. The computerreadable medium of claim 15, wherein the method further comprises inresponse to receiving a transaction confirmation from the second device,providing a response.
 17. The computer readable medium of claim 16,wherein providing the response comprises sending a confirmation to thefirst device.
 18. The computer readable medium of claim 16, furthercomprising: prior to creating the secure image, receiving userinformation including financial information; wherein the secure imagerepresents the one or more transaction details and does not representthe financial information.
 19. The computer readable medium of claim 15,wherein the method further comprises authenticating the second device.20. The computer readable medium of claim 19, wherein authenticating thesecond device comprises checking the location of the second deviceagainst a known location for the first device.